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(54) Method for call admission in a packet voice system 



(57) An AAL2/SSCS packet voice system multiplex- 
es various forms of voice-band traffic including voice 
packets, fax packets, and data packets into a virtual cir- 
cuit (VC). This AAL2/SSCS packet voice system exe- 
cutes a dynamic call admission algorithm that takes into 
account call type in deciding whether to admit a new call 
to the VC. In particular, this approach takes into account 



different bandwidth needs for different call types. The 
AAL2/SSCS packet voice system also performs bit or 
block dropping on voice packets to mitigate the effects 
of traffic congestion. The bit or block dropping is done 
based on the packet queue fill value exceeding at least 
one queue threshold. Further, the AAL2/SSCS packet 
voice system also dynamically varies a queue threshold 
as a function of capacity. 
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Description 

Field of the Invention 

[0001 ] Th is invention relates generally to communica- $ 
tions and, more particularly, to a communications sys- 
tem for transporting packet voice. 

Background of the Invention 

[0002] Asynchronous transler mode (ATM) networks 
carry fixed sized cells within the network irrespective of 
the applications being carried over ATM. At the network 
edge or at the end equipment, an ATM Adaptation Layer 
(AAL) maps the services offered by the ATM network to 
the services required by the application. There are a 
number of industry standards and proposed standards 
covering various AALs. In particular, "B-ISDN ATM Ad- 
aptation Layer Type 2 Specification," draft Recommen- 
dation 1.363.2, November 1996, of ITU-T (herein re- 
ferred to as AAL2) provides for efficient ATM transport 
of small, delay-sensitive packets in such applications as 
packet voice systems. AAL2 is partitioned into two sub- 
layers, the Common Part Sublayer (CPS) and the Serv- 
ice Specific Convergence Sublayer (SSCS). 
[0003] In an AAL2/SSCS packet voice system, the 
peak required raw bandwidth of voice, coded in accord- 
ance with ITU-T standard embedded ADPCM G.727 
(hereafter referred to as G.727), is 32 thousands of bits 
per second (kb/s). However, other types of voice-band 
type traffic are also carried in this system besides voice 
itself. For example, G3 facsimile (fax) traffic may be con- 
veyed requiring a typical bandwidth of 9.6 kb/s. Also, 
data traffic may be carried with required bandwidths of 
as much as 64 kb/s in the case of 56 kb/s modem tech- 
nology. 

[0004] As a result, an AAL2/SSCS packet voice sys- 
tem multiplexes a variety of traffic types onto an outgo- 
ing ATM virtual circuit (VC) pipe, which has a fixed band- 
width allocation in accordance with an ATM service cat- 
egory, e.g., ATM Constant Bit Rate (CBR), ATM Real- 
Time Variable Bit Rate (rt-VBR). (This bandwidth is typ- 
ically fixed, or static, and negotiated with a distant ATM 
endpoint at setup of the VC.) Once the VC is set up, new 
calls may be admitted to the VC in accordance with a 
call admission algorithm. In this call admission algo- 
rithm, all traffic is treated in a homogeneous fashion in 
one extreme. A new call is admitted simply by compar- 
ing the current number of calls in the respective VC to 
a predetermined call threshold value. If the current 
numberof calls is less than this call threshold value, then 
the new call is admitted. Otherwise, the new call is 
blocked. 

[0005] Unfortunately, as new calls are admitted to the 
pipe, traffic loads may necessitate the use of congestion 
relief algorithms for the voice traffic such as bit dropping 
or dropping entire AAL2 voice packets. (It is presumed 
that only voice traffic is throttled to relieve congestion 



and that non-voice traffic is not targeted for packet drop- 
ping in order to provide for congestion relief.) For exam- 
ple, as congestion begins to occur, voice packets are 
typically queued for transmission in a buffer, or queue. 
If the number of these queued voice packets exceeds a 
predetermined threshold, bit dropping for voice traffic 
begins to occur in accordance with, e.g., G.727. If the 
congestion continues to worsen, then entire AAL2 voice 
packets are dropped. (Also, it should be noted that if the 
above-mentioned thresholds are too small, bit dropping 
occurs too soon, and if the above-mentioned thresholds 
are too large, bit dropping occurs too late. In this latter 
case, there is almost little, or no, benefit from bit drop- 
ping (in the context of G.727) because of the already 
incurred large packet delay by the time bit dropping be- 
gins to start.) 

Summary of the Invention 

[0006] In view of the above, we have observed that a 
call admission control strategy that treats all calls in a 
homogenous fashion either admits too few calls — thus 
causing some calls to be blocked even though capacity 
exists — or too many calls — with concomitant conges- 
tion effects. As such, we have realized that a call admis- 
sion control strategy should take into account different 
call types in order to provide for efficient bandwidth man- 
agement In particular, and in accordance with the in- 
vention, call admission is dynamically performed as a 
function of call type. 

[0007] In an illustrative embodiment, an AAL2/SSCS 
packet voice system multiplexes various forms of voice- 
band traffic including voice packets, fax packets, and 
data packets into a virtual circuit (VC). This AAL2/SSCS 
packet voice system executes a dynamic call admission 
algorithm that takes into account call type in deciding 
whether to admit a new call to the VC. In particular, this 
approach takes into account different bandwidth needs 
for different call types. 

[0008] In accordance with a feature of this invention, 
at least one queue parameter is dynamically varied as 
a function of capacity (or link bandwidth). An example 
of a queue parameter is a threshold. 

Brief Description of the Drawing 

[0009] 

FIG. 1 shows illustrative ATM cells and AAL2 for- 
matting; 

FIG. 2 shows a packet header of an LLC packet in 
accordance with AAL2; 

FIG. 3 shows a start field of an ATM cell in accord- 
ance with AAL2; 

FIG. 4 shows a portion of a packet communications 
system in accordance with the principles of the in- 
vention; 

FIG. 5 shows an illustrative table listing call types 
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and bandwidths; 

FIG. 6 shows an alternative view of the portion of 
the communications system shown in FIG. 4; 
FIG. 7 shows an illustrative graph of effective band- 
width and statistical multiplexing gain; 
FIG. 8 shows a flow chart of a call admission pro- 
cedure embodying the principles of the invention; 
FIG. 9 shows a flow chart of a call departure proce- 
dure for use with the call admission procedure of 
FIG. 8; 

FIG. 10 shows an illustrative organization of an 
AAL2 voice packet; 

FIG. 11 shows a congestion state table; 
FIG. 12 shows a flow chart for dynamically varying 
block dropping thresholds in accordance with the 
principles of the invention; 

FIG. 13 shows another embodiment of a packet 
communications system embodying the principles 
of the invention; and 

FIG. 14 shows another embodiment of a packet 
communications system embodying the principles 
of the invention. 

Detailed Description 

[0010] Before describing an illustrative embodiment 
of the invention, some background information on ATM 
Adaptation Layers (AALs) and, more particularly, AAL2, 
is provided. 

AAL2 

[0011] ATM networks carry fixed size (53 octets) cells 
within the network irrespective of the applications being 
carried over ATM. To support applications in native pro- 
tocol mode, a Terminal Adapter (TA) at the network edge 
acts as an 'ATM user 1 and implements an ATM Adapta- 
tion Layer (AAL) to map the services offered by the ATM 
network to the services required by the applicatbn. In 
cases where ATM is terminated at the end user equip- 
ment, the AAL entity is implemented there. AAL-1 has 
been defined for Constant Bit Rate (CBR) traffic requir- 
ing tight delay and jitter control (e.g., see ITU-T Recom- 
mendation 1.363.1 B-ISDN ATM Adaptation Layer AAL- 
1 Specification). Also AAL-3/4 (e.g., see ITU-T Recom- 
mendation 1. 363.3/4 B-ISDN ATM Adaptation Layer 
AAL 3/4 Specification) and AAL-5 (e.g., see ITU-T Rec- 
ommendation 1. 363.5 B-ISDN ATM Adaptation Layer 
AAL-5 Specification) have been defined lor bursty data. 
These AALs allow simple encapsulation of application 
'packets' il each packet fits into one ATM cell. For larger 
application packets, a segmentation and reassembly 
(SAR) layer allows segmentation of a 'packet' at the 
transmitter, so each segment fits into an ATM cell, and 
reassembly of the original packet from the received ATM 
cells at the receiver. These AALs thus allow collection 
of enough information to fit into one ATM cell payload or 
segmentation of larger native mode packets into smaller 



units such that each smaller unit fits into an ATM cell 
payload. If native information units are smaller than an 
ATM payload, these AALs require partial fill of ATM celts. 
[0012] However, many applications require ATM 

s transport of 'small packets' that are smaller than the 
ATM ceil size. Some of these applications are: PBX-to- 
PBX trunking for compressed voice with or without si- 
lence suppression; ATM backbone for cellular/PCS 
wireless access; ATM trunking between circuit switches; 

10 and ATM backbone connectivity to packet telephony. 
[0013] In applications like the ones mentioned above, 
there are two primary reasons to transmit small packets 
across ATM networks: (i) when small native packets are 
generated away from the ATM network and the packet 

is boundaries need to be recovered at the destination out- 
side ATM network; and (ii) when the bit rate of a native 
application is low and the requirement on the end-to-end 
delay prohibits accumulation of bits to fill an ATM cell 
before sending the cell out to its destination. In the latter 

20 case, small packets are generated even if the packeti- 
zation is done at the ATM network edge. Use of an ATM 
network to connect base stations to vocoder groups in 
digital cellular systems is an example of the former. ATM 
trunking between circuit switches or circuit PBXs is an 

25 example of the latter. 

[0014] For these applications, partial fill of ATM cells 
resulting from use of AAL-1, AAL-3/4, or AAL-5, may 
cause unacceptable loss in bandwidth efficiency. This 
inefficiency is of concern due to high cost/bps (bits per 

30 second) when the total traffic demand needs only low 
speed teased lines. In many cases, this cost penalty 
may nullify many of the advantages offered by an ATM 
backbone. This necessitates use of an AAL for small 
packets such as AAL2. The latter provides efficient 

35 transport of small native packets over ATM networks in 
such a way that allows very small transfer delay across 
the ATM network and still allows the receiver to recover 
the original packets. 

[001S] AAL2 treats the payloads from successive 

40 ATM cells from the same ATM connection as a byte 
stream in which variable length Logical Link Connection 
(LLC) packets are multiplexed. Each LLC packet stream 
originates from one end user connection such as a 
voice, facsimile, or voice-band data (VBD) call. An illus- 

45 tration of ATM cells and AAL2 formatting is shown in 
FIG. 1 . An ATM connection comprises a plurality of ATM 
cells, a portion of which is represented by the sequence 
of ATM cells 50, 51, and 52. Each ATM cell comprises 
an ATM header 1 (as known in the art), an STF field 2 

so and a plurality of LLC packets 3 (defined below). Each 
LLC packet, as represented by LLC packet 60 compris- 
es a packet header 61 and a native LLC packet 62. 
[0016] The packet header is 3 octets long and is 
shown in detail in FIG. 2. The packet header comprises 

ss four fields: a Channel ID (CID) field, a Length Indicator 
(LI) field, a Reserved (RES) field, and a Header Error 
Check (HEC) field. 

[0017] The CID field is 8 bits long and identifies the 
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LLC to which the packet belongs. (Referring briefly back 
to FIG. 1 , it can be observed that the CID field value for 
the associated LLC packet corresponds to the LLC 
number.) The CID field provides support for a maximum 
of 255 native connections (LLCs) over a single ATM VC. 
As known in the art, an ATM cell header allows two lev- 
els of addressing: a Virtual Path Identifier (VPI) and Vir- 
tual Connection Identifier (VCI). A Virtual Path Connec- 
tion (VPC) can have a number of VCs. With a 1 6 bit VCI 
field, an ATM VPC can support up to 255 x 2 16 LLCs. 
[0018] The LI field is 6 bits and indicates the length of 
the LLC packet (or native packet). The LI field is added 
to each LLC packet so that the end of variable length 
packets can be demarcated. The LI field allows specifi- 
cation of up to 63 octets. When the value of the LI field 
points beyond the end of the current ATM cell, the pack- 
et is split between cells (this is also illustrated in FIG. 1 , 
where LLC packet 60 is split between ATM cells 50 and 
51). 

[001 9] Since the primary driver for AAL2 is packet te- 
lephony., and error detection is not essential for voice 
coding algorithms, error detection for native packets is 
not necessary. The purpose of error detection is to guar- 
antee that CID, LI and other critical protocol header 
fields do not get misinterpreted. This is accomplished in 
AAL2 by the HEC field in each packet header. The HEC 
field is 5 bits (see FIG. 2) and provides error detection 
over the packet header. This has the advantage of being 
able to discard only those packets whose headers are 
corrupied. 

[0020] AAL2 is partitioned into two sublayers, the 
Common Part Sublayer (CPS) and the Service Specific 
Convergence Sublayer (SSCS). The RES field compris- 
es five bits, which are reserved or assigned to either the 
CPS or a Service Specific Convergence Function (SS- 
CF) of the SSCS. The CPS provides the functions of 
multiplexing variable length packets from multiple 
sources into a single ATM virtual circuit and relaying 
these packets to form end-to-end AAL2 connections. 
That portion (not shown) of the RES field assigned to 
the CPS are used to provide signaling such as a "More" 
bit to indicate that the current packet is segmented, sig- 
naling, or user information. The remaining portion (not 
shown) of the RES field assigned to the SSCF provides 
an application specific function, a different instance of 
being provided to each AAL2 user. Examples of such 
functions are segmentation and reassembly of user 
flows into packets suitable for the common part, forward 
error control, identifying the voice coding algorithm, 
identifying the end of a speech burst, packet sequence 
number, etc. The SSCS can also be null. (At this point, 
the ITU-T standards body intends to specify SSCS pro- 
tocols in future recommendations.) These SSCF-orient- 
ed bits are not interpreted by the AAL2 CPS and are 
passed transparently from the transmitting SSCS to the 
receiving SSCS. The SSCS may use these bits for spe- 
cific SSCF functions or to pass higher layer user-to-user 
communication transparently. 



[0021] As can be observed from FIG. 1 , a Start Field 
(STF) is present at the beginning of each ATM cell pay- 
load from a given ATM connection. The format of the 
STF field is shown in FIG. 3. An STF field is 1 octet in 

s length and comprises an Offset field (OSF), a Sequence 
Number (SN) field and a Parity (P) field. 
[0022] While the LI field in each LLC packet allows 
self delineation once a packet boundary is identified, a 
cell loss or an error in a packet header results in the loss 

10 of packet delineation. In order to regain packet bound- 
aries, the OSF field specifies the beginning of the first 
new packet in the current ATM cell payload. The OSF 
field is 6 bits in length and indicates the remaining length 
of the packet that (possibly) started in the preceding cell 

15 from this ATM connection and is continuing in the cur- 
rent cell. This approach guarantees resynchronization 
of packet boundaries in one ATM cell time after a delin- 
eation loss. 

[0023] Given that a loss of an ATM cell, if not detected 
20 at the receiver, can misconcatenate packets, the SN 
field also exists. The one bit SN field provides a modulo 
2 sequence numbering of cells and immediate detection 
of a single cell loss. It may be noted that this 1-bit se- 
quence number is different from the earlier-mentioned 
25 sequence number which is part of the RES field in the 
AAL2 packet header. 

[0024] Finally, like the packet header, the SN field and 
OSF field also require error detection. This is provided 
by the single parity bit of the P field, which provides odd 
30 parity. 

[0025] It should be noted that it may be necessary to 
transmit a partially filled ATM cell in order to limit the 
packet emission delay. In this case, the remainder of the 
ceil is padded with all-zero octets. A cell whose payload 
35 contains only the STF field and 47 padding octets can 
also be transmitted in order to meet some other needs 
such as serving a "keep-alive" function, satisfying a traf- 
fic contract, etc. 

[0026] AAL2 creates multiple levels of connections 

40 between two points: ATM virtual connections (VCs) and 
AAL2 Logical Link Connections (LLCs). The AAL2 LLC 
in this case is defined to be a point-to-point connection, 
for example, between a base station and the vocoder 
group in the Mobile Switching Center (MSC) for cellular 

45 trunking, or between two PBX?s or two switches for land- 
line trunking. The connection is defined to be bi-direc- 
tional and the same CID is assumed to be used in both 
directions for a particular LLC. The set of C IDs available 
on an ATM VC are known to both ends. 

so [0027] The negotiation procedures are symmetric, 
that is, either end of the AAL2 connection is permitted 
to initiate a new LLC or request tear down of an LLC. A 
simple negotiation procedure is defined where the orig- 
inating end proposes establishment of a new LLC with 

55 the use of a particular CID that is not in use and the other 
end can accept or deny the request Bandwidth man- 
agement and monitoring for the ATM virtual circuit is as- 
sumed to be handled at the ATM connection manage- 
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ment level. No such monitoring is proposed per LLC. 
However, it is the responsibility of the two end points to 
guarantee resource availability within the ATM connec- 
tion to support a new LLC. Such resource management 
is assumed to be handled in a service specific manner. 
Signaling needed for LLC set up and tear down between 
AAL2 uses a predefined LLC (with ClD=0). 

Call Admission 

[0028] A portion of a packet communications system 
in accordance with the principles of the invention is 
shown in FIG. 4. Other than the inventive concept, the 
elements shown in FIG. 4 are well-known and will not 
be described in detail. For example, although shown as 
a single block element, call controller 110, ot call proc- 
essor 1 25, includes stored-program-control processors, 
memory, and appropriate interface cards. Other than the 
inventive concept, call processor 125 implements an 
AAL2/SSCS voice packet system. (It should also be not- 
ed that like numbers in different figures are similar ele- 
ments.) 

[0029] PBX 105 transmits and receives a plurality of 
voice-band calls to call controller 110 of call processor 
125, via facility 106. The latter is representative of any 
number and type of communications facilities. To facili- 
tate the description it is assumed that facility 106 is a 
DS1 tacility (for each direction) as known in the art, 
which carries a plurality of voice-band calls. As such, it 
is presumed that for each call there is a 64 kb/s bit 
stream in either direction over facility 106. 
[0030] Before describing the inventive concept in de- 
tail, a general overview of the operation of call processor 
125 is provided. Call processor 125 comprises call con- 
troller 110, AAL2/SSCS processor 130 and ATM proc- 
essor 135. For each call, call controller 110 first classi- 
fies the voice-band call. (Call classification techniques 
are known in the art and will not be described herein. 
For example, G3fax calls are identified by detecting pre- 
defined fax calling tones, etc.) As noted above, there 
are a variety of different types of voice-band calls. An 
illustrative list of some call types is shown in the table 
of FIG. 5. This table also lists illustrative bandwidths at 
different points in the call processing (described below). 
This table assumes a 5 milli-second (ms) AAL2/SSCS 
packetization interval in all cases. In addition, it is as- 
sumed that activity for a voice call is equal to 40% (av- 
erage talkspurt = 400 ms, and average silence = 600 
ms). Call controller 1 1 0 associates a predefined call type 
with each call. For the purposes of illustration only, this 
example includes four voice-band call types. A voice call 
is associated with call type "0,° a data call with a data 
rate of less than 28.8 kb/s is associated with call type 
"1 a data call with a data rate of 28.8 kb/s to 56 kb/s is 
associated with call type "2," and a G3 fax call is asso- 
ciated with call type '3." (Additional definitions of other 
call types could also be used. For example, the charac- 
terization of data call types according to speed could be 



finer, e.g., a call type for each available industry stand- 
ard modem data rate.) 

[0031] If call controller 110 detects a voice call, then 
the voice call is encoded in accordance with G.727. As 

s such, call controller 110 compresses the 64 kb/s bit 
stream from PBX 1 05 into a 32 kb/s compressed audio 
stream using ADPCM as known in the art for application 
to AAL2/SSCS processor 1 30. Similarly, in the other di- 
rection, call controller 110 decompresses the 32 kb/s 

10 ADPCM bit stream provided by AAL2/SSCS processor 
130 into a 64 kb/s audio stream for application to PBX 
105. 

[0032] On the other hand, if a non-voice call is detect- 
ed, call controller 110 provides an encoded data stream 

is at the indicated bandwidths. For example, a 14.4 kb/s 
Voice Band Data (VBD) call is transmitted using 40 kb/ 
s ADPCM to AAL2/SSCS processor 1 30, and a 28.8 kb/ 
s or 56 kb/s VBD call is transmitted using 64 kb/s PCM 
(pulse code modulation). 

20 [0033] Turning now to AAL2/SSCS processor 130, it 
converts received bit streams, from call controller 110, 
into AAL2 packets for application to ATM processor 1 35. 
In this conversion, the SSCS portion of processor 130 
performs functions such as silence suppression, assign- 

25 ment of sequence numbers, and background noise level 
notification. In the opposite direction, AAL2/SSCS proc- 
essor 1 30 receives AAL2 packets from ATM processor 
135 and depacketizes them. AAL2/SSCS processor 
1 30 provides functions such as buffering (not shown) for 

30 build-out delay before playing out packets for transmis- 
sion to call controller 110; and noise fill during silence 
period. In playing out the packets, AAL2/SSCS proces- 
sor 130 makes use of sequence numbers to decide de- 
layed packets and to maintain integrity in the play-out 

35 process. The required bandwidth for transmission using 
AAL2 for the different call types is shown in FIG. 5. (The 
peak numbers listed for a voice call represents periods 
of talking, or talk spurts.) 

[0034] ATM processor 135 provides the following 
40 transmit functions: filling payioad of ATM cells with AAL2 
packets; forming an ATM cell whenever the payioad is 
filled-up or a timer (e.g., 2 milli-seconds (ms)) expires 
with at least one AAL2 packet in the payioad (whichever 
of the two events happens first); ATM cell header 
45 processing; placing ATM cells into a transmit buffer, etc. 
ATM processor 135 schedules ATM cells for transmis- 
sion over an ATM VC through an ATM network 1 00. ATM 
processor 135 receives ATM cells from ATM network 
100 and provides the following receive functions: ATM 
so cell header processing and error control; transferring 
AAL2 packets to AAL2/SSCS processing unit, etc. The 
required bandwidth for transmission including AAL2 and 
ATM overhead for the different call types is shown in 
FIG. 5. 

ss [0035] In order to better illustrate the principles of the 
invention, an alternative view of the portion of the com- 
munications system shown in FIG. 4 is shown in FIG. 6. 
In this representation, facility 1 06 is shown as conveying 
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m voice-band calls to call controller 110, as described 
above. AAL2/SSCS processor 130 comprises AAL2 
packetization and block dropping element 140, and 
AAL2 queue 145 (described below). As can be ob- 
served, an AAL2/SSCS packet system multiplexes a va- 
riety of traffic types onto an outgoing ATM virtual circuit 
(VC) pipe, or facility, which has a fixed bandwidth C kb/ 
s. This fixed bandwidth is determined a priori or negoti- 
ated with a distant ATM endpoint, as known in the art. 
[0036] As noted earlier, as new calls are placed from 
PBX 105 to call controller 110, these new calls must ei- 
ther be accepted into the associated VC or blocked. 
Therefore, and in accordance with the invention, call 
processor 1 25 implements a call admission strategy that 
is dynamically performed as a function of call type. In 
particular, this approach takes into account different 
bandwidth needs for different call types, and also takes 
advantage of statistical multiplexing of voice calls. It is 
assumed that silence elimination is applied to voice 
calls, i.e., no packets are transmitted during silence pe- 
riods. 

[0037] It should be noted that the following assump- 
tions have been made for the below-described compu- 
tations concerning capacity and effective bandwidth. Ef- 
fective bandwidth, V n , is the minimum bandwidth that is 
required per voice call when n voice calls are statistically 
multiplexed while meeting performance objectives such 
as listed below. Statistical multiplexing gain is defined 
as the ratio of peak bandwidth of a voice call to its ef- 
fective bandwidth, V n . 

[0038] Example performance objectives for 
AAL2/SSCS voice multiplexing with bit dropping: 

(1) Average packet queuing delay < 5 ms, 

(2) Tail of packet queuing delay (mean plus 5 * std 
dev) £ 15 ms, 

(3) Mean bits per sample > 3.3, and 

(4) Packet loss (buffer overflow) probability < 10" 4 , 

[0039] Example performance objectives for 
AAL2/SSCS voice multiplexing without bit dropping: 

(1) Average packet queuing delay < 5 ms, 

(2) Tail of packet queuing delay (mean plus 5 * std 
dev) < 10 ms, and 

(3) Packet loss (buffer overflow) probability < 10 -3 . 

[0040] In some instances of system implementation, 
bit dropping may be disabled or not at ail included as a 
feature. Bit dropping may be disabled, for example, 
when the traffic is dominated by data and fax, and only 
a small fraction of the traffic is voice. Although bit drop- 
ping is assumed in the description below, it should be 
noted that this system can also operate without bit drop- 
ping. Statistical multiplexing of voice may be done in ei- 
ther case (i.e., with bit dropping or without). When voice 
is statistically multiplexed, temporary traffic overloads 
occur which result in excessive voice packet delay or 



loss. However, bit dropping mitigates the effects of these 
overloads by allowing less significant bits to be selec- 
tively dropped during the temporary overload periods 
(described in more detail later). Bit dropping results in 
5 smaller packet delays, and hence allows for better sta- 
tistical multiplexing gain as compared to the case of no 
bit dropping (for a given ATM VC bandwidth). This com- 
parison is well illustrated by the example numerical data 
plotted in FIG. 7. 
10 [0041] For reference purposes only, FIG. 7 shows a 
graph of illustrative simulation results for effective band- 
width per voice source (in kb/s) (left ordinate axis) ver- 
sus number of admitted voice sources; and statistical 
multiplexing gain (stat mux gain) (right ordinate axis) 
is versus the number of admitted voice sources. (The de- 
tails concerning statistical multiplexing gain are known 
in the art and will not be described herein. Since voice- 
band data and fax have fixed bandwidths, these signals 
do not get the benefits of statistical multiplexing.) 
20 r [0042] The following system and state data definitions 
are made for the communications system of FIGs. 4 and 
6 (these parameters/variables are presumed to be avail- 
able to the elements of call processor 125, e.g., stored 
in memory): 

25 

n~ Number of voice (embedded ADPCM) calls in 
progress; 

V n = Effective bandwidth required to admit a new 
voice call, with nnew calls present (see FIG. 7); 
30 c= Total bandwidth available for the VC: 

G = Total bandwidth currently allocated to data and 
fax calls; 

B i— Fixed bandwidth required to admit a non-voice 
call of type /, for #= 1,2 t ...,k; 
35 w- Spare bandwidth, (initially, W = C); and 

B 0 - Initial bandwidth for call admission = 64 *43/40* 

53/47 = 77,6 kb/s; 
C v = Bandwidth available for voice = C - G; 
O, = First block dropping threshold for voice; 
40 q 2 = Second block dropping threshold for voice; and 
K- AAL2 packet buffer limit. 

It should be noted that in the definition for B& the ratio 
of 43/40 represents the added AAL2 overhead, and the 

45 ratio of 53/47 represents the added ATM cell overhead. 
[0043] Reference should now be made to FIG. 8 
which illustrates a call admission control algorithm in ac- 
cordance with the principles of the invention for use in 
call controller 110 of call processor 125 of FIGs. 4 and 

so 6. (It is presumed that call processor 1 25 is suitably pro- 
grammed to carry out the below-described algorithm us- 
ing conventional programming techniques, which, as 
such, will not be described herein.) 
[0044] In step 400, a call arrives via facility 106 from 

55 PBX 1 05 (shown in FIG. 4). In step 405, a check is made 
if the spare bandwidth, W, is greater than the initial 
bandwidth, Bq, for call admission. If the spare band- 
width, W t in not greater than Bq, then the call is rejected 
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in step 430. Otherwise, the call is admitted in step 410 
and the spare bandwidth, W, is updated to: W- W- B& 
It should be noted, and as described below, that the 
spare bandwidth W is temporarily reduced by B 0 be- 
cause it takes up to 50 ms to classify a call. As such, in 
this example a call is admitted if at least B 0 bandwidth 
is initially available. 

[0045] In step 415, identification of call type is per- 
formed. Steps 420 and 425 update the value of the 
spare bandwidth as a function of the identified call type. 
[0046] If the call is type "0 I U i.e., voice, then, in step 
425, the value of the spare bandwidth, W, is updated to 
be equal to the capacity of the ATM VC reduced by a) 
the bandwidth, G, assigned to data and fax, and b) the 
bandwidth, (n + 1 ) V n + 1 now assigned to voice calls. 
At this point, the number of voice calls admitted, n, is 
increased, n<- n + 1. 

[0047] If the call type is other than "0, " e.g. , fax or data, 
then, in step 420, the value of the bandwidth, G, as- 
signed to data and fax is increased, G <- G + B b where 
B t - is the bandwidth of the identified call type, as shown 
in the table of FIG. 5. In addition, the value of the spare 
bandwidth, IV, is updated to be equal to the capacity of 
the line reduced by a) the bandwidth, G, assigned to da- 
ta and fax, and b) the bandwidth, nV n , assigned to voice 
calls. In addition, instep 425, the block dropping thresh- 
olds (Q 7 , K) are varied in accordance with the new 
bandwidth values since the bandwidth available for 
voice C v has now changed (described below). 
[0048] At the end of steps, 420, 425, and 430, call con- 
troller 110 waits for the next call. 
[0049] Turning now to FIG. 9, a method is shown, in 
accordance with the principles of the invention, for up- 
dating the above-described system and state parame- 
ters when a call departs the system shown in FIGs. 4 
and 6. This method is illustratively performed by call 
controller 110 of FIGs. 4 arid 6. 

[0050] When a call departs the system, in step 450, 
the call type (previously identified in step 415 of FIG. 8) 
is retrieved in step 455. If the call is type "O," i.e., voice, 
then, in step 460, the value of the spare bandwidth, W, 
is updated to be equal to the capacity of the line reduced 
by a) the bandwidth, G, assigned to data and fax, and 
b) the bandwidth, (n - 1)V n . v now assigned to voice 
calls. At this point, the number of voice calls admitted, 
n, is reduced, n 4- n - ). 

[0051 ] If the call type is other than °0, ■ e.g. , fax or data, 
then, in step 465, the value of the bandwidth, G, as- 
signed to data and fax is reduced to: G <- G - B h where 
B /is the bandwidth of the identified call type, as shown 
in the table of FIG. 5. In addition, the value of the spare 
bandwidth, W, is updated to be equal to the capacity of 
the line reduced by a) the bandwidth, G, assigned to da- 
ta and fax, and b) the bandwidth, nV n , assigned to voice 
calls. In addition, in step 465, the block dropping thresh- 
olds (Q 1t K) are varied in accordance with the new 
bandwidth values since the bandwidth available for 
voice C v has now changed (described below). 



[0052] As noted in steps 425 and 465 of FIG. 9, and 
in addition to the above described dynamic call admis- 
sion strategy, queue, or buffer, parameters are also var- 
ied as a function of bandwidth. Returning to FIG. 6, 

s AAL2 packet queue 145 has a fixed size K (in bytes). 
AAL2 packet queue 1 45 provides a cu rrent voice packet 
fill value, q, to AAL2 packetization and block dropping 
element 140 via signal 146. (Although shown as mark- 
ers on AAL2 packet queue 1 45, the values for K, Q 1 and 

10 Q 2 are stored in AAL2 packetization and block dropping 
element 140.) This current fill value, q, represents the 
number of voice packets queued for transmission. As 
known in the art, traffic bursts (i.e., the arrival of many 
voice packets in a short time) may cause the number of 

15 AAL2 voice packets queued up for transmission, q. to 
increase. When the value of q reaches some predefined 
thresholds, block dropping occurs (also known in the art 
as bit dropping). 

[0053] FIG. 10 shows an illustrative organization of an 
20 AAL2 voice packet. Each AAL2 voice packet comprises 
23 bytes formatted into a header portion (3 bytes) and 
four blocks, each block 5 bytes long. In accordance with 
G.727, blocks # 2 and # 3 represent the more significant 
bits, while blocks # 0 and # 1 represent the less signifi- 
es cant bits. Block # 3 and block # 2 are never dropped 
(except when packet is dropped due to buffer overflow), 
while block # 0 or Blocks # 0 and # 1 may be dropped 
during traffic congestion. An illustrative table indicating 
these effects is shown in FIG. 11 . 
30 [0054] The parameters Q v Q 2 , and Kare block-drop- 
ping thresholds specified in terms of number of AAL2 
voice packets. As noted above, the queue-fill, q, is the 
number of AAL2 voice packets waiting in the buffer 145 
for transmission (see FIG. 6). In the prior art, the values 
35 of Q p and Kare predetermined and fixed. The table 
of FIG. 11 illustrates that for particular ranges of the val- 
ue of q, different forms of congestion relief occur. For 
values of q < Q 7 , no AAL2 voice bits or packets are 
dropped. For values of q within the range of Q 7 < q < 
40 bit dropping occurs, and block 0 of each incoming 
AAL2 voice packet (at the input to queue 1 45 in FIG. 6) 
is dropped. For values of q within the range of Q 2 < q ^ 
K- 1, bit dropping occurs, and blocks 0 and 1 of each 
incoming AAL2 voice packet are dropped. Finally, for 
45 values of q > K, whole voice packets are dropped. Re- 
ferring back to FIG. 6, AAL2 packetization and block 
dropping element 1 40 performs the bit dropping or pack- 
et dropping at the input to AAL packet queue 145. This 
is referred to herein as "input block dropping." 
50 [0055] in accordance with a feature of the invention, 
the following algorithm dynamically varies the values for 
the parameters Q v Q 2 , and K. It is assumed herein that 
the AAL2 voice packets (amenable to block dropping) 
are queued together with packets of other calls, e.g., fax 
55 and data. However, the value of the queue-fill, q, used 
in the block dropping algorithm pertains only to the 
number of AAL2 (block-droppable) voice packets wait- 
ing in the buffer for transmission. (It is assumed that the 
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AAL2 packets are distinguished on the basis of their CID 
value, as is known in the art. In particular, some CID 
values are associated with voice and other CID values 
are associated with non-voice. This association is pro- 
vided by call controller 110.) 

[0056] As defined above, let C v be the bandwidth 
available for block-droppable voice. If, for example, 
there are no fax and data calls present in the system, 
and the traffic is all voice (block-droppable), then Cy is 
equal to the ATM VC bandwidth of C kb/s. Otherwise, 
C V =C- G, where G represents bandwidth (in kb/s) as- 
signed to existing fax and data calls. 
[0057] An illustrative algorithm for dynamically vary- 
ing the parameters Q v Q 2 , and Kas a function of avail- 
able voice bandwidth, C v , is shown in FIG. 12 for use in 
call controller 110 of FIGs. 4 and 6. (In this example, the 
thresholds obtained by this algorithm ensure that the 
packet delays corresponding to the buffer fill values of 
Q 1t Q 2% and K, are approximately 5 ms, 10 ms, and 15 
ms, respectively (or lower for the range of the link band- 
width values). In step 300, call controller 11 0 determines 
the available voice bandwidth, C v . The values for the 
block-dropping thresholds are a function of the available 
voice bandwidth, C v% determined in step 300 (e.g., see 
steps 310, 320, 330, 340 and 350). If the value of C v \s 
less than 333 kb/s : then the values for the block-drop- 
ping thresholds are Q 1 = 10, Q 2 = 20, and K= 30 (steps 
310 and 330). If the value of C v is more than 1000 kb/ 
s, then the values for the block-dropping thresholds are 
Q 1 = 30, Q 2 = 60, and K= 90 (steps 320 and 350). Oth- 
erwise, the values for Q 1t Q 2 , and Kare determined by 
the equations shown in step 340. (The symbols r 1 are 
representative of taking the "ceiling of the value, i.e., 
the next highest integer value.) The new values of Q p 
and Kare provided to AAL2 packetization and block 
dropping element 140 via signal 147 (see FIG. 6). 
[0058] The above examples for bit dropping and pack- 
et dropping were with respect to "input block dropping. 
" However, the above-described algorithm can also be 
used with other architectures, e.g., with "output block 
dropping." An alternative architecture using "output 
block dropping" is shown in call processor 600 of FIG. 
13. (It should be noted that voice quality effects as well 
as packet delay performance are known to be practically 
indifferent to input or output block dropping (while the 
VC bandwidth, C, and Q v Q 2 , K values are the same).) 
In call processor 600, since block dropping is performed 
after AAL2 packetization, element 160 not only performs 
block dropping as described above, but also updates the 
AAL2 length field appropriately. 

[0059] Another alternative architecture is shown in 
FIG. 14. In this figure, "input bit dropping 1 ' is performed 
in a similar manner as described above. However, the 
queuing is performed by the ATM processor, which com- 
prises ATM Cell Creation element 170 and ATM Cell 
Queue 175 of call processor 700. The above-described 
algorithm for dynamically varying the values for the pa- 
rameters O v and K f is suitably modified to take into 
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account the number of ATM cells (which convey voice) 
queued for transmission as opposed to the number of 
AAL2 voice packets queued for transmission. 
[0060] As described above, a packet voice system uti- 
5 lizes a call admission algorithm that dynamically han- 
dles both statistically multiplexed calls and other call 
types such as fax and voice-band data of various mo- 
dem speeds. 

[0061] The foregoing merely illustrates the principles 
10 of the invention and it will thus be appreciated that those 
skilled in the art will be able to devise numerous alter- 
native arrangements which, although not explicitly de- 
scribed herein, embody the principles of the invention 
and are within its spirit and scope. For example, the call 
1$ admission control algorithm of the inventive concept is 
also applicable to non-packetized systems such as dig- 
ital circuit multiplication equipment (DCME) well known 
in the art. The algorithm is generally applicable inde- 
pendent of the modulation schemes used which may in- 
20 elude discrete multi-tone (DMT), quadrature phase shift 
keying (QPSK), or quadrature amplitude modulation 
(QAM), etc. Further, the invention is also applicable to 
TDMA as well as CDMA wireless systems. 

25 X' 
Claims 

1. A method for use in a packet communications sys- 
tem, which provides access to at least one virtual 

30 circuit, the method comprising the steps of: 

determining a call type of an incoming call; each 
call type having an associated bandwidth; 
admitting the incoming call to use the virtual cir- 

35 curt if the associated bandwidth of the incoming 

call is not greater than a spare bandwidth that 
is associated with the virtual circuit; 
responsive to the admitted call, providing a 
stream of ATM Adaptation Layer 2 (AAL2) 

40 packets for conveying information associated 

with the admitted call; and 
responsive to the stream of AAL2 packets, pro- 
viding a respective stream of ATM cells for 
transmission over the virtual circuit. 

45 

2. The method of claim 1 further comprising the step 
of blocking the incoming call if the incoming call is 
not admitted. 

50 3. The method of claim 1 wherein the admitting step 
includes the step of reducing the spare bandwidth 
by an amount equal to the call bandwidth of the ad- 
mitted incoming call. 

55 4. The method of claim 1 further comprising the step 
of increasing the spare bandwidth by an amount 
equal to the call bandwidth of the admitted incoming 
call when the admitted incoming call departs. 
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5. The method ol claim 1 further comprising the step 
ot updating a count of a number of voice calls cur- 
rently admitted, when the admitted incoming call is 
a voice call. 

6. The method of claim 1 , further comprising the steps 
of 

determining an amount of bandwidth available 
for voice as a function of a number of non -voice 
admitted calls on the virtual circuit; 
setting a value of at- least -one parameter as a 
function of the determined amount of band- 
width, wherein the at-least-one parameter is 
associated with a buffer for holding AAL2 voice 
call traffic for transmission over the virtual cir- 
cuit; and 

performing block dropping on the held AAL2 
packets as a function of the set value of the at- 
least-one parameter value. 

7. The method of claim 1 , further comprising the steps 
of 

determining an amount of bandwidth available 
for voice as a function of a number of non-voice 
admitted calls on the virtual circuit; 
setting a value of at-least-one parameter as a 
function of the determined amount of band- 
width, wherein the at-least-one parameter is 
associated with a buffer for holding ATM cells 
conveying AAL2 voice call traffic for transmis- 
sion over the virtual circuit; and 
performing block dropping on the held ATM 
cells as a function of the set value of the at- 
least-one parameter value. 

8. Apparatus for use in a packet communications sys- 
tem, which provides access to at least one virtual 
circuit, the apparatus comprising: 

a call classifier for determining a call type of an 
incoming call; each call type having an associ- 
ated bandwidth and for admitting the incoming 
call to use the virtual circuit if the associated 
bandwidth of the incoming call is not greater 
than a spare bandwidth that is associated with 
the virtual circuit; 

a processor responsive to the admitted call for 
providing a stream of ATM Adaptation Layer 2 
(AAL2) packets for conveying information as- 
sociated with the admitted call; and 
a processor responsive to the stream of AAL2 
packets for providing a respective stream of 
ATM cells for transmission over the virtual cir- 
cuit. 

9. The apparatus of claim 8 wherein the call classifier 



blocks the incoming call if the incoming call is not 
admitted. 

10. The apparatus of claim 8 wherein the call classifier 
5 reduces the spare bandwidth by an amount equal 

to the call bandwidth of the admitted incoming call. 

11. The apparatus of claim 8 wherein the call classifier 
increases the spare bandwidth by an amount equal 

io to the call bandwidth of the admitted incoming call 
when the admitted incoming call departs. 

12. The apparatus of claim 8 wherein the call classifier 
updates a count of a number of voice calls currently 

is admitted, when the admitted incoming call is a voice 
call. 

13. The apparatus of claim 8 wherein the call classifier 
further (a) determines an amount of bandwidth 

20 available for voice as a function of a number of non- 
voice admitted calls on the virtual circuit; and (b) 
sets a value of at-least-one parameter as a function 
of the determined amount of bandwidth, wherein 
the at-least-one parameter is associated with a buff- 

25 sr for holding voice call traffic for transmission over 
the virtual circuit; and wherein the processorfor pro- 
viding the stream of AAL2 packets performs block 
dropping on the held voice call traffic as a function 
of the set value of the at-least-one parameter value. 

30 

14. The apparatus of claim 8 wherein the call classifier 
further (a) determines an amount of bandwidth 
available for voice as a function of a number of non- 
voice admitted calls on the virtual circuit; and (b) 

35 sets a value of at-least-one parameter as a function 
of the determined amount of bandwidth, wherein 
the at-least-one parameter is associated with a buff- 
er for holding voice call traffic for transmission over 
the virtual circuit; and wherein the processorfor pro- 

40 viding the stream of ATM cells performs block drop- 
ping on the held voice call traffic as a function of the 
set value of the at-least-one parameter value. 
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